ソフトウェアアーキテクチャの基礎輪読会 1章
日付：11/1
調査者：takasshii.icon
1章
ソフトウェアアーキテクトには明確なキャリアパスがない
理由1
アーキテクチャとは（それが何であれ）重要なものだ
理由2
アーキテクチャの役割が広範囲で拡大を続けている
ex.
10年前まではモジュール、コンポーネント、パターンとった純粋な技術的な側面だけで良かったが、現在では、マイクロサービスのような広範囲の能力が必要となった
理由3
ソフトウェア開発エコシステムが急速に進化している
今日のいかなる定義も、数年後には時代遅れになってしまうことは避けられない。
ソフトウェアアーキテクチャは動的なものである
理由4
ソフトウェアアーキテクチャについての資料の大変が歴史的経緯となってしまっている
ソフトウェアアーキテクチャの歴史を学ぶ = 失敗から教訓を学ぶ
数年前であれば間違いなく有効だったソリューションでさえ、文脈の変わった現在では機能しないものとなっている。
なぜ今ソフトウェアアーキテクチャを学ぶのか
アーキテクチャを取り巻くエコシステムは刻一刻と変化している
アーキテクチャは文脈によって成り立つものであることを理解する必要があるから
ex.
20世紀前半ではインフラが高価だったが今は安価になった
1.1 章 ソフトウェアアーキテクチャの定義
構成要素
1. システムの構成
アーキテクチャスタイルの種類
ex. マイクロサービス，クリーンアーキ，レイヤード
2. システムがサポートしなければならないアーキテクチャ構成
システムの成功基準
ex. 信頼性、スケーラビリティ、テスト用意性
3. アーキテクチャ決定
何が許されて何が許されないかを決める
ex. ビジネス層とサービス層のみがDBにアクセスをし、プレゼンテーション層が直接DBを呼び出すのを制限する
4. 設計指針
ガイドラインや望ましいアプローチ
ex. マイクロサービス間は非同期メッセージングを利用してパフォーマンスを向上させるのが望ましい→RESTやgRPCなどを選択
1.2 アーキテクトへの期待
アーキテクトは以下の8つが期待される
1. アーキテクチャ決定を下す
アーキテクチャの技術的な選択を決定 or ガイドする
2. アーキテクチャを継続的に分析する
今のアーキテクチャが存続力（健全性）があるのかをビジネスと技術の両面から評価する
コーディングや設計を変更する中で以下のことが達成されているかを評価する
パフォーマンス
可読性
テスト容易性
3. 最新のトレンドを把握し続ける
アーキテクチャの変更は長い間影響を与え、変更が難しいので、適切判断を下すために業界の動向を理解する必要がある
4. 決定の順守を徹底する
開発チームが設計指針に従っているかを検証する
5. 多様なものに触れ、経験している
現在の環境は異種混合のものとなっているため、さまざまなプラットフォームに慣れ親しんでいることが期待される
1種のキャッシュソフトウェアの専門家であるよりも、10種のキャッシュソフトウェアのそれぞれの長所と短所を押さえている方が、はるかに価値がある。
6. 事業ドメインの知識を持っている
事業ドメインについて理解しなければ、ビジネス上の問題や目標、要件を理解するのは難しい
7. 対人スキルを持っている
アーキテクチャ決定や設計指針の伝達がうまくいかない原因は、対人スキルにある
8. 政治を理解し、舵取りする
アーキテクトが下すほとんどの決定は反発される
アーキテクチャ決定は、コストや作業量の増加から、ビジネス側のステークホルダーから反発される
アーキテクトが行う決定は広義なものになる
1.3 アーキテクチャと交わるもの
従来、アーキテクチャと開発プロセスは分離されていた
近年、プロセスに関する問題がソフトウェアアーキテクチャの領域に入り込んできた
プロセスの問題領域に適したアーキテクチャスタイルがある
未知の未知（誰も予測していなかったこと）によって予測や見積もりが難しい問題がある
この問題に対処するためには、イテレーティブ（反復型）のプロセスのアーキテクチャが適している
アーキテクチャスタイルとエンジニアリングスタイルには共生関係が存在している
ex. マイクロサービスアーキテクチャには自動化されたテストやデプロイといった前提がある
アーキテクチャ適応度関数
適応度関数という考えが用いられる
最適解に近いか遠いかを判定するためのもの
アーキテクチャではこの考えを応用した、アーキテクチャ適応度関数を提案する
アーキテクチャ特製の整合性を客観的に評価するもの
ex. ページ読み込み時間を重要な特性とした場合は、読み込み時間を計測するテストを適応度関数として構築し、テストを実行する
運用とDevOps
運用場の関心事をアーキテクチャと組み合わせた新しいアーキテクチャの形態が生まれた
開発プロセス（ソフトウェアの作り方）
ソフトウェアの作り方とアーキテクチャは影響を及ぼさないとする公理があるが、実際は影響を与えている
データ
データベースなどの外部の関心事もアーキテクチャの一面である
ソフトウェアアーキテクチャの法則
ソフトウェアアーキテクチャの第一法則
ソフトウェアアーキテクチャはトレードオフが全てだ
必然的帰結その1
アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していないだけの可能性が高い
ソフトウェアアーキテクチャの第二法則
「どうやって」よりも「なぜ」の方がずっと重要だ
アーキテクチャの決断を下す理由の方が重要である
応用
コードが出てこなかったのでなし
質疑応答
チャを決める活動
〇〇アーキテクチャの実践！とかではなく、要件定義や開発運用、品質特性や品質保証といった広義の設計と開発に関わる活動を指している
参考になりそうな記事